home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Aminet 9
/
Aminet 9 (1995)(GTI - Schatztruhe)[!][Dec 1995].iso
/
Aminet
/
game
/
think
/
Dragon.lha
/
Dragon
/
Dragon.doc
< prev
next >
Wrap
Text File
|
1995-03-09
|
9KB
|
236 lines
**********************************************************************
****************************** DRAGON ******************************
**********************************************************************
©1994 by Nick Christie
Distributed under the terms
of the GNU General Public License.
What's Dragon?
==============
It's a little board game I cooked up. It's not my game originally,
actually, having been invented by the Chinese zillions of years ago (I
think that's right). Also, there has been at least one other Amiga
incarnation, though I've forgotten the name and author.
Anyway, there were problems with that version, like not multi-tasking
correctly (I hate that), so I copied the rules and produced Dragon.
It's not been fully "polished" up, I must admit, but I never seemed to
get round to adding the final touches. You know how it is, when you
get distracted by yet another cool idea that you've just got to work
on... yeah, that's right, I'm lazy and undisciplined!
Enough ranting, on with the doc!
I bet you're going to include the boring legal bumph, right?
============================================================
Only for Americans - everybody else is more sensible about these
things. :-)
This program, its source code, documentation and related files are
Copyright © Nick Christie. I have placed this program under the
governance of the GNU General Public License as published by the Free
Software Foundation; either version 2 or (at your option) any later
version. See the separate GNU License file for the details of this
licensing agreement.
This program is distributed WITHOUT ANY WARRANTY; without even the
implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE. See the GNU General Public License for more details.
OK, I'll try it. Will it run on my Amiga?
=========================================
Any Amiga with OS2.04 (Kickstart V37) or better. Dragon uses one
external library (in LIBS:), iffparse. This is a standard Commodore
library, so you should already have it.
Where should I put the program?
===============================
Put "Dragon", "DragonBgnd.pic" and "DragonTiles.pic" together in any
directory you like. Simple.
That's good, but how do I start it?
===================================
You can start it from the Shell or Workbench. It always operates on
its own custom screen - lores 320 by 256 in 32 colours. Ooops. Forgot
about NTSC. Sorry, USA! Hmmm, should fix that up...
There are two possible tooltypes or shell arguments:
TILES = the name of an IFF ILBM file to get the tile images from.
BGND = the name of an IFF ILBM file to get the background image from.
The background is optional, the tiles aren't. Default filenames are
DragonTiles.pic and DragonBgnd.pic, which assumes these files are in
the same directory as Dragon. See the section a little later on about
how to supply your own images - there are some restrictions.
Fine, now what's the game about?
================================
Finally we get to the game itself. When you start, you'll see on
screen a collection of game pieces, like Mahjong tiles, laid out in an
initial configuration, with some stacked on top of others. Hope you
can see the 3D effect. Each tile has a symbol on the upper side, with
four tiles sharing an identical symbol.
Your aim is to remove all the tiles from the board, in pairs having
the same symbol. If you can see two tiles with, for example, the alpha
symbol on them, you would click on the first, and then on the second.
They would then both be removed from the board, possibly exposing
further tiles below them.
That sounds too simple, what's the catch?
=========================================
Well, the catch is this: you can only remove a tile if it has no
neighbours to the left or right. That's all, you ask? Well, yup, it's
true that initially you will find that quite a few tiles are "mobile",
and that, as you remove pairs of tiles, more tiles become available,
but pretty soon you'll start to see the dependencies creep in.
Eventually you'll either get stuck and lose (unable to remove any more
tiles), or if you're lucky, you'll be able to remove all the tiles.
Yippeee!
Now I haven't programmed in any "end game" effects - the polishing I
talked about, above - but it's pretty obvious when you've won, since
there'll be no tiles left. You'll just have to pat yourself on the
back! As for losing, read below to find out what those numbers on the
screen mean.
And what about those numbers on screen, eh?
===========================================
Let's start on the righthand side of the screen, where you'll see two
numbers displayed. The one above tells you how many pairs of tiles are
left on the board, and the one below tells you how many pairs of tiles
are removeable (having no neighbouring tile to the left or the right).
When the latter number drops to zero, and there are still tiles on the
board, you've lost. Hard luck, hehe.
Over on the lefthand side of the screen is one further number. When
you have clicked on a tile which can be removed, an image of the tile
displayed here, plus a number which tells you how many pairs of tiles
with that symbol are left on the board. If you think about it, this is
only ever "1" or "2", since only four tiles have the same symbol. To
make things really easy for you, an asterisk "*" is shown next to the
number if the tile has a pair somewhere on the board that is also
removeable.
Alright, that's not a brilliant description, but if I keep going I'll
probably confuse myself as well! Trust me, it's not complicated, just
click around the screen and you'll see. I'd better go and strike
communication skills off my resume.
Wait a minute, can all arrangements of tiles be completed?
==========================================================
No. It's possible, for example, to end up with four tiles with the
same symbol stacked on top of each other, which could never be
removed. Fortunately :-), Dragon checks for this situation (and
several other insoluble ones) and reshuffles the board if required.
Still, I'm not guaranteeing that every board presented to you will be
solvable - I just think I've eliminated all those combinations.
Go on, tell me about the menu items.
====================================
Ah, yes. "New Game" starts a... yeah, you guessed it. The tiles are
shuffled, though, so you end up with a different arrangement.
"Restart" puts all the tiles back where they were when you started the
game. "Undo Move" is for when you've made a mistake and removed the
wrong pair of tiles. In fact, you can undo multiple moves all the way
back to the beginning (sneaky, huh?). "About" tells you who wrote the
program (me!), and "Quit" shouldn't need any explanation.
Did you say I could use my own images?
======================================
Yup, but you have to follow these rules:
The background picture must be an IFF ILBM, 320 by 256 pixels in size,
and 4 bitplanes deep (that means 16 colours). The first four colours
(pens) are reserved by Dragon, though you can assume pen 0 is black.
That leaves you with 12 colours to play with as you please. For the
technically minded, the image is blitted into bitplanes 1 to 4 of the
screen, and pens 4 to 15 in the image are copied to screen pens 20 to
31.
The tile picture is also an IFF ILBM file, 320 by 96 pixels in size,
and 4 bitplanes deep (16 colours). The tiles are laid out in a
particular fashion within this image. I suggest you load the supplied
"Template.pic" file into your paint package, draw within the tile
borders and save the image as brush 320 pixels wide, 96 pixels high.
You can freely choose the colours for pens 2 to 15 for the tiles;
Dragon defines pen 0 as black and pen 1 as white.
I can do better, where's the source code?
=========================================
That's included, for SAS/C 6.51 and DevPac3. The only assembler bit is
some minimal startup code which should be easily converted to other
assemblers (I know, I know, shouldn't roll your own startups, but...).
This requires the use of registerized parameters in the C code, and
also supplies main() with the command line and length (or the
WBStartup message), rather than the usual argc and argv.
Note the funny make file used by own Make utility - you should be
able to convert this into the incomprehensible U*IX type quite
easily, though.
And please, if you distribute modified versions, keep a log of the
changes made, when, and by whom. You might even credit me as the
original author. That would be polite.
Dragon's great! I want to send you loads of money for it.
=========================================================
Hehe. I wish. You can reach me, for the moment anyway, at
nick.christie@computing-services.oxford.ac.uk
or if your mailer spews on that one,
nick@vax.ox.ac.uk
If you must use snail mail,
Nick Christie
39 St Georges Drive
Bransgore
BH23 8EZ
Great Britain
Have fun!